Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

I just skipped through this PR; thank you for making it. Maybe I did not see it, but how would you protect the /admin route? The main reason I had this not configurable was that only 'real' admins could expose images they wanted. The must in this PR would be to make sure that no other users can change configs and display images they should not see. I'd also prefer not to add too much complexity. On the other hand, having a UI to change config values would be a welcome change.

cc @3rob3

Thanks for the review and for calling this out - agreed that /admin needs to be protected.

I had multiple points coming up when thinking about your valid questions. To get my thoughts across, I had the LLM summarize them below 😄

What “protect /admin” means today

ImmichFrame currently has a single shared trust boundary:

• If a user has the Immich API key, they can query anything that key can access.
• If a user has the ImmichFrame AuthenticationSecret, they can call the protected endpoints we expose.

So: protecting /admin prevents unauthorized config changes, but it doesn’t create per-user image isolation. Anyone who can control config and/or holds the Immich API key (directly or indirectly) can make the frame show “any album in that Immich account”.

Minimal, low-complexity fix

• Add a separate AdminSecret (env/config only; not stored in DB).
• Require it for:
  • Serving /admin (server-side check before returning the SPA)
  • GET/PUT /api/Config/account-overrides
  • GET/PUT /api/Config/general-settings
• Keep slideshow client behavior on the existing AuthenticationSecret.
• Treat SSE similarly (either keep it unauthenticated but emit only non-sensitive events, or accept a token via query param since EventSource can’t set headers).

This keeps complexity low while ensuring “non-admin viewers” can’t change config to expose albums/people they shouldn’t.

Bigger picture: “real admins” vs multi-user

I think your concern is correct: true per-user access control (each user only sees what they’re allowed to see) isn’t solvable purely by hiding ImmichFrame config. That’s a broader architecture topic:

• We’d need a multi-user model (users, roles), per-frame config, and likely per-user Immich tokens (or an auth delegation model) so the frame only sees what a given user grants.
• At that point, it starts to overlap heavily with Immich’s own auth/permissions UX and infra.

That’s why I’m not convinced ImmichFrame should grow into a full multi-user management system. Once we go there, it may make more sense to push the “frame UI / slideshow capabilities” into Immich core, leveraging Immich’s existing user/session/permission model (this aligns with my earlier direction in immich-app/immich#24627).

TL;DR

• This PR can and should protect /admin and config endpoints via a simple AdminSecret split from AuthenticationSecret.
• It cannot (and shouldn’t try to) solve “multi-user image isolation” without a bigger redesign; that’s either a larger ImmichFrame roadmap decision or better handled upstream in Immich core.